Extant file system management models are limited in that the order in which a filter loads dictates the order in which the filter attaches to a critical volume. Such systems are inflexible with respect to variation in the ordering of filters. For example, an operating system will notify a filter that registers for such notifications, that there is a file system loading. A file system creates a device object as it loads, and the file system provides information to the file manager regarding the contents of the file system.
Traditional systems require that filters attach to a critical volume in the order in which they load. Legacy filters do not have dynamic loading capabilities, but rather must load as load-order groups (antivirus, encryption, quota, etc.). Such filters are typically layered from top to bottom. For example, legacy filters must load at a predetermined time in accordance with an associated start-type, which results in inflexibility of the filter system. Conventional start-types can be, for instance, “boot,” whereby a filter or driver is loaded at start-up; “system,” which denotes that a file system is already loaded, and that a next phase of drivers is incoming; “auto,” whereby drivers are automatically loaded before login; “manual,” whereby a user must explicitly start the driver; and “disable,” which describes a driver that does not load or start. Legacy filters have specific start-types assigned to them, and, thus, can determine when they boot relative to each other. For example, if a legacy filter L1 has associated with it a “boot” start-type and filter L2 has associated with it a “system” start-type, L1 will load first. Depending on the function of the filters, this can be problematic in that it can unnecessarily increase the time required to perform a given function. For instance, it is often desirable to load an encryption filter before loading an antivirus filter. However, if the start-types dictate that an antivirus filter loads prior to an encryption filter, ineffectiveness is inevitable. Such ineffectiveness occurs because the antivirus filter in this case only sees encrypted I/O, and, therefore, cannot detect viruses. Furthermore, the loading order of two filters in the same load order group and having the same start-type (e.g., “boot”) cannot be predicted or guaranteed, thus further increasing inefficiency and the potential for undesirable loading sequences.
Software modules such as file system filter drivers can be stacked or otherwise arranged linearly (e.g., chained), and perform their operations in the order in which they are stacked. For example, in the Windows® 2000 operating system, file system filter drivers are stacked into a driver stack where they are able to intercept file system-directed requests and responses to and from a base file system (such as FAT or NTFS). In this manner, the drivers can, for example, scan file data for viruses, enforce disk usage quotas, encrypt data, and perform other similar functions.
While it is often useful to run more than one such filter driver for each file storage volume of a computer system, these filters are written by a number of vendors, and software bugs often result from interoperability issues between the various filters. Testing has discovered that such bugs often depend on the order in which drivers are loaded and/or attached to the filter driver stack. Additionally, certain combinations of filters can only work properly when attached in a certain order. For example, to be effective, an antivirus filter, which reads the contents of a file to look for viruses, needs to see the data before the data is scrambled by an encryption filter.
Contemporary operating systems, such as Microsoft Corporation's Windows® XP operating system, with an underlying file system such as the Windows® NTFS (Windows® NT File System), FAT, CDFS, SMB redirector filesystem, or WebDav file systems, permit one or more file system filter drivers to be inserted between the I/O manager that receives user I/O requests and the file system driver. In general, filter drivers (‘filters’) are kernel-mode drivers that enhance the underlying file system by performing various file-related computing tasks that users desire, including tasks such as passing file system I/O (requests and data) through anti-virus software, file system quota providers, file replicators and encryption/compression products. For example, antivirus products provide a filter that watches I/O to and from certain file types (.exe, .doc, etc.) looking for virus signatures, while file replication products perform file system-level mirroring. Other types of file system filter drivers are directed to system restoration (which backs up system files when changes are about to be made so that the user can return to the original state), disk quota enforcement, backup of open files, undeletion of deleted files, encryption of files, and so forth. Thus, by installing file system filter drivers, computer users can select the file system features they want and need, in a manner that enables upgrades, replacement, insertion, removal of the components without necessitating the changing the actual operating system or file system driver code.
The existing file system filter model in contemporary Windows®-based operating systems (e.g., Windows® NT, Windows® 2000, Windows® XP, Windows® .NET Server 2003) leverages the inherent I/O model, which is a packet-based approach. To this end, file system filters load as regular drivers in a stack and attach to the underlying file system's volume device objects. User I/O requests are converted by an I/O manager into I/O Request Packets (IRPs), which are sent to the driver stack and processed by the top driver, which can complete it, pass it down in a call to another driver towards the file system, which in turn calls the next lower driver, and so on. In general, each driver does whatever processing it is coded to perform on the IRP, and then explicitly passes down the IRP to the next lower driver (or file system if none are lower), or completes (or fails) the IRP and sends it back up the stack to the next higher driver (or the I/O manager if none are higher).
Another problem is efficiency, as file system filters traditionally receive and process every operation that normally goes to a file system, even those in which they have no interest. For example, an antivirus product can slow down a system as much as sixty percent, but not every I/O request received by an antivirus filter is one upon which the filter will act (e.g., inspect corresponding data for viruses). Redundancy is also a problem that leads to inefficiency and computing cost, as many filters perform similar functions in different manners, leading to unnecessary code.
Interoperability between drivers is also a significant problem, as, for example, one driver can modify I/O in a way that another driver does not anticipate and cannot properly deal with. Note that interoperability problems are one of the biggest drawbacks of the existing model, in part because filters have only limited control over ordering of attachment to a file system.
Other problems include overflowing stack space, because when two or more filters are installed, stack overflows are common due to recursive reentrant I/O issued by filters. Deadlocks are also common in the existing model, again primarily due to re-entrant I/O. Further problems include the inability to dynamically load and unload filters in the stack without a system reboot.